Relocation

The expanded GOT is defined by four new Relocation Types which are added to <elf.h>;.

		 Figure 1.  Expanded GOT Relocation Types

Name              Value   Field     Symbol          Calculation
______________________________________________________________________
R_MIPS_GOTHI16  |  22   | T-hi16 | external | (G - (short)G) >> 16 + A
________________|_______|________|__________|_________________________
R_MIPS_GOTLO16  |  23   | T-lo16 | external |  G & 0xffff
________________|_______|________|__________|_________________________
R_MIPS_CALLHI16 |  30   | T-hi16 | external | (G - (short)G) >> 16 + A
________________|_______|________|__________|_________________________
R_MIPS_CALLLO16 |  31   | T-lo16 | external |  G & 0xffff
________________|_______|________|__________|_________________________

The first instance of R_MIPS_GOT16 or R_MIPS_GOTHI16 and R_MIPS_GOTLO16 or R_MIPS_CALL16 or R_MIPS_CALLHI16 and R_MIPS_CALLLO16 relocations cause the link editor to build a global offset table if one has not already been built.

R_MIPS_CALL16 or R_MIPS_CALLHI16 and R_MIPS_CALLLO16 relocation entries load function addresses from the global offset table and indicate that the dynamic linker can perform lazy binding. See "Global Offset Table" in Chapter 5 of the processor specific ABI.

	#define R_MIPS_LOVENDOR   100  /* Vendor specific relocations */
	#define R_MIPS_HIVENDOR   127

Link Editing

This problem occurs only when an ISV's application is link edited after installation (i.e., uses the ld command to build itself). If all executables and shared libraries are built on the Reference Platform and pass the Application Compliance Testing tool (ACT), the only possible external interfaces are those specified by the ABI. (Note that ACT does not test manifest constants, such as ioctl calls compiled into the program.) The ABI interfaces are present on all ABI conforming Operating Systems in the form of dynamic shared libraries. Thus they will be resolved through dynamic linking to the dynamic shared libraries at run-time.

In the case where an application link edits itself after installation, it may expose an incompatibility between non- ABI headers or libraries on the Reference Platform and another vendor's platform. Furthermore, vendors may change the interface or implementation of libraries not covered by the ABI in new operating system releases.

The MIPS ABI Group offers the following guidelines to ISV's whose applications must link edit after installation; they are not meant to be either exhaustive or foolproof:

• Compiler and linker flags are known to differ across the various platforms. To aid the ISV, each vendor has agreed to provide a consistent interface in the wrappers abicc and abild, which are defined further in in this chapter.
• The math routines in libm.a will be consistent across all vendor's platforms.
• libcurses.a is known to depend on private interfaces in libc.so.1 and should be avoided if possible, but limited functionality may be used from it if care is taken.
• Implementations of libucb.a may not be compatible across all vendor's platforms and should not be used.
• ISV's should document the version of any system interface used by their application that is not supported by the ABI. For example, applications using X widgets, X extensions, Motif or other system libraries which must be linked statically should document the release level of these libraries. This will allow customers to compare release levels between the application and their system.
• Not all compilation systems behave the same with respect to conflicts with the ANSI C Strict Ref/Def Initialization model (see section 3.1 of the ANSI C Standard and elaboration in 3.1.2.2 of the Rationale for ANSI C; and note that section numbering is different in the ISO version). Some platforms emit warnings from the loader, while others a fatal error. If code is generated on a platform of the former type, it may link on that platform but not on some others. Application source code should be modified such that each external data symbol is defined in exactly one place, done by omitting the extern keyword. All other references should use the extern keyword.

Object Files

Debugging

The abicc wrapper supports the following flags, many are described in more detail in the cc(SD_CMD) page in the

• -A controls #assert mechanisms.
• -B symbolic, -Bsymbolic, -B dynamic, -Bdynamic, -B static, -Bstatic controls linking phase library name lookup.
• -C controls comment removal.
• -c suppresses linking phase.
• -D controls #define mechanisms.
• -dn, -d n, -dy, -d y selects dynamic (y) or static (n) linking.
• -E preprocess only (no compilation or linking).
• -f obsolete, ignored.
• -G direct linker to produce shared object.
• -g generate symbolic debug information.
• -H prints include file names as they are processed.
• -I controls include file lookup.
• -Jsfm not supported, silently ignored.
• -Kfpe, -K fpe, -Kmau, -K mau, -Ksd, -K sd, -Ksz, -K sz not supported, silently ignored.
• -KPIC, -K PIC generate Position Independent Code (this is the default for the MIPS ABI).
• -Kminabi, -K minabi restrict libraries to ABI definitions (not needed for MIPS ABI, ignored).
• -Kxgot, -K xgot generate code to use an expanded Global Offset Table (GOT).
• -L controls library search path at linking phase.
• -l search specified library.
• -o names output file.
• -O controls optimization.
• -P perform only preprocessing.
• -p generate profiling code.
• -Qn, -Q n, -Qy, -Q y generates compiler identification in output.
• -q controls generation of profiling code.
• -S suppress assembly and linking (leaves assembler file).
• -U causes specified name to be undefined.
• -V prints version information.
• -W not supported, generates a warning message.
• -Xa, -X a, -Xc, -X c, -Xt, -X t controls conformance to ANSI and ISO C standards.
• -Xreadwrite const, -X readwrite const place const data in writable memory. Selecting this option is a violation of the ANSI C standard.
• -Xreadonly const, -X readonly const place const data in read-only memory. This is the default.
• -Y not supported, generates a warning message.

• -a undefined references generate errors (static mode).
• -b controls DSO linkage.
• -dn, -d n, -dy, -d y selects dynamic (y) or static (n) linking.
• -e defines entry point.
• -h controls dynamic linking name lookup.
• -l search the specified library.
• -m produce a memory map.
• -o names the output file.
• -r combine object files.
• -s strip symbolic information.
• -t suppress warning about multiple defined symbols of different sizes.
• -u enters named symbol as an undefined.
• -zdefs, -z defs, -znodefs, -z nodefs, -ztext, -z text controls handling of undefined symbols.
• -Bsymbolic, -B symbolic, -Bdynamic, -B dynamic, -Bstatic, -B static control lib. name lookup
• -G produce shared object.
• -I specifies an interpreter to be linked with a.out.
• -L controls library lookup path.
• -M use specified map file.
• -Qn, -Q n, -Qy, -Q y add compiler identification strings to output.
• -V output a version identifier string.
• -Y controls library search list.

Copyright © 1995, MIPS ABI Group, Incorporated.